A multitude of different fixed and mobile telecommunication/datacommunication services have been developed, in addition to traditional voice calling and short text messaging. For example, Internet browsing has rapidly become very popular, and in recent years the wireless domain has converged with the Internet. Mobile terminals are now available having functionality for connecting to the Internet over a wireless access network to obtain information and services from sites and servers located anywhere throughout the world.
Moreover, new technologies for mobile communication are introduced, providing greater network capacity and higher transmission bit rates. In particular, GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) networks are currently emerging for enabling wireless data services that require a wide range of different data rates. The data communicated in many new services may include voice, text, images, audio files and video files in various different formats and combinations.
By way of example, mobile instant messaging, commonly known as “chatting”, and presence services are rapidly becoming popular. Instant messaging is known from the world of fixed PCs (Personal Computers), including message status reporting and various group and contact list features. Presence services involve information on the location of mobile terminals and enable users to receive messages according to their profile and availability. A user profile can be personal and may be defined by preferences, interests and hobbies, as well as more temporary factors, such as user availability and current moods. Messages and content services can also be delivered depending on the present location, availability and terminal capabilities. It can be readily understood that such services require the storage of considerable amounts of retrievable user-specific data, which in many cases need to be frequently updated due to their dynamic nature.
The demands for telecommunication services are thus increasing rapidly, and service providers are established all over the world, equipped with hardware and software resources to meet these demands. In particular, means for processing service requests and data, as well as means for storing huge amounts of data are needed. Consequently, a service provider must be able to efficiently control the processing and storing means which typically comprise a system of different service components such as servers. The expression “server” will be used hereafter to represent any hardware and/or software for storing and/or processing data. A server may be configured to provide one or more specific services.
For an Internet service provider or the like controlling a plurality of servers, processing and storing load must be distributed over the servers. This is necessary in order to efficiently utilise available computing and storing resources, and to handle hotspots and avoid bottlenecks. As mentioned above, large amounts of data must be stored and should also be easy to find and retrieve.
As seen from the examples of services given above, different types of stored data may be of a very dynamic nature, needing frequent updating. Moreover, server systems must be reconfigured from time to time as the processing and storing load change, e.g., due to changing demands of service requests, added or removed subscribers and the introduction, modification or deletion of services. The workload on servers may increase rapidly so that individual servers are easily overloaded, at least for a short time, in particular popular web servers. To overcome overloading problems in servers; basically two solutions are available.
Firstly, an existing server may be upgraded to increase its computing and/or storing capabilities. However, the server will soon become overloaded again if the amount of service requests and/or needs for data storage continue to increase. Further upgrading is then required, which can be complex and costly to perform.
Secondly, it is possible to add further servers to meet a higher load. The concept of virtual servers has been proposed to provide load sharing between plural servers. A virtual server is a scalable server built on a cluster of real servers, which is transparent to end users such that the users see only a single virtual server. The front-end of the real servers is a node, sometimes referred to as a “load balancer”, configured to schedule service requests to the different real servers. Incoming service requests may involve processing tasks and storing tasks to be performed by the servers. Scalability can thus be achieved by transparently adding or removing servers in the cluster.
However, it is a problem to efficiently distribute processing and storing tasks between a plurality of servers, yet enabling easy retrieval of stored data. “Processing tasks” may involve analysing service requests, processing of data and running certain applications for delivering requested services. “Storing tasks” may involve storing new client-specific, session-specific or configuring data, updating already stored data, and retrieving stored data. For example, a service request may require the retrieval of certain data which is used as input for executing a specific processing task or service application. Client data and session data is hereafter collectively referred to as “user data”.
In current solutions involving the distribution of processing and storing tasks, a server is often allocated to a client upon a login request. The allocation scheme used for selecting a server is normally based on the current load on a predetermined set of servers, such that the server having the lowest current load, with respect to memory resources and/or CPU (Central Processing Unit) capability, etc, is selected for a client or session. Server allocation is typically performed by using a central load manager node or the like. Stored user data must then be retrievable, i.e. it must be possible to find the server in which the searched data was stored.
The most simple current solution for selecting a server is to use a “Round Robin” allocation scheme. Further load sharing solutions are known which are more complex, such as “Weighted Round Robin”, “Least Connection”, “Weighted Least Connection”, “Locality Based Least Connection”, “Destination Hashing” and “Source Hashing”.
However, the solutions mentioned above are relatively complex to use, resulting in problems related to supervision, operation and maintenance, since it is difficult to predict where data will be distributed and stored. Furthermore, it may be difficult to find and retrieve data being stored in one or more servers if no reference or pointer to the data is stored as well. A client performing a login may have a proper reference to the data, but no other client or device can find and retrieve the data without the reference, unless so-called “brute force searches” are used among a set of servers.
“Round Robin” scheduling is only suitable for distributing processing load, since processing tasks are not affected by in which server they are performed. On the other hand, retrieving stored data in one of more servers carrot be done by using Round Robin but requires the use of specific pointers or references as described above. Furthermore, a common basic problem with some of the other scheduling methods mentioned above is that they use is (Internet Protocol) addressing for scheduling. Since a plurality of clients can reside behind a single IP address (proxy, NAT, etc.), these can neither be used for data distribution nor load sharing.
Storing tasks are therefore preferably scheduled by means of a hashing algorithm using some client or session identity as input. The hashing algorithm then provides a number identifying a selected server. If the same hashing algorithm is used again when retrieving data on a later occasion for the same client or session, the same server will be selected, provided that the servers have not been reconfigured since the searched data was stored. Thereby, the need for using specific pointers or references is eliminated.
However, if the number of servers and/or the identities of individual servers are changed in a reconfiguration operation, the hashing algorithm will most probably not provide the correct server identity anymore, if user data for a specific client or session was stored before the reconfiguration was made. A current solution for avoiding this problem is to shut down the server system from service requests for modifying the hashing algorithm and moving stored user data between servers, such that server selection becomes correct. This is a quite cumbersome and time consuming operation, which is undesirable since service requests cannot be attended meanwhile, resulting in lost revenue for the service provide. Moreover, the reconfiguration operation is relatively complex involving a considerable risk for errors.